How does this differ from the recently-added Embedded category?

Granted there would be a lot of overlap, however...

#![no_std] is a pretty specific need: any project using #![no_std] can only transitively depend on #![no_std]-compatible crates.

Right now there simply isn't a good way to discover this information about crates. You can look through their source code or check their README, but you can't easily browse/search for crates which explicitly meet this requirement.

Shortly before Cargo categories were announced I posted this question on the internals Discourse:

https://internals.rust-lang.org/t/no-std-true-metadata-in-cargo-toml/4684

To make a specific point about how this differs from embedded though... from the "Embedded" description:

Crates that are primarily useful on embedded devices or without an operating system.

#![no_std] is also useful for things like authoring operating systems or other OS infrastructure (e.g. a "libc" in Rust) which could run on systems that very much aren't embedded (e.g. your typical Dell PowerEdge-style server).

The actual use case is probably closer to "systems programming" than "embedded development". I would say "embedded development" is a subset of #![no_std] use cases.

Generally I think of #![no_std] as being an entirely separate ecosystem of crates. If crates.io had an advanced search, it's the sort of thing that probably deserves a checkbox.

I think categories could suffice to accomplish the same thing though, if there were e.g. a "search within a category" feature

Ok. When we were bikeshedding the initial set of categories, we were shying away from kinds of categorization that wasn't topic related (that is, would be useful to someone looking for "a crate that does X"). But I can see this being useful, and since we don't have a no_std badge/checkbox mechanism now...... let's give this a try.

Issue #491 is for tracking search within a keyword or category, which I agree would also be useful.

Awesome, thank you!